Extending Knowledge-Level Contingent Planning for Robot Task Planning

We present a set of extensions to the knowledge-level PKS (Planning with Knowledge and Sensing) planner, aimed at improving its ability to generate plans in realworld robotics domains. These extensions include a facility for integrating externally-defined reasoning processes in PKS (e.g., invoking a motion planner), an interval-based fluent representation for capturing the effects of noisy sensors and effectors, and an application programming interface (API) to facilitate software integration on robot platforms. We demonstrate our techniques in three simple robot domains, which show their applicability to a broad range of robot planning applications involving incomplete knowledge, real-world geometry, and multiple robots and sensors. Introduction and Motivation A robot operating in a real-world domain often needs to do so with incomplete information about the state of the world. A robot with the ability to sense the world can also gather information to generate plans with contingencies, allowing it to reason about the outcome of sensed data at plan time. In this paper, we explore an application of planning with incomplete information and sensing actions to the problem of task planning in robotics domains. In particular, building models of realistic domains which can be used with generalpurpose planning systems often involves working with incomplete (or uncertain) perceptual information arising from real-world sensors. Furthermore, this task may be complicated by the difficulties of bridging the gap between geometric and symbolic representations: robot systems typically reason about joint angles, spatial coordinates, and continuous spaces, while many symbolic planners work with discrete representations in represented in logic-like languages. Our approach makes use of the PKS (Planning with Knowledge and Sensing) planner (Petrick and Bacchus 2002; 2004) as the high-level reasoning tool for task planning in robotics domains. PKS is a general-purpose contingent planner that operates at the knowledge level (Newell 1982), by reasoning about how its knowledge changes due to action during plan generation. PKS is able to represent known and unknown information, and model sensing actions using concise but rich domain descriptions, making it well Figure 1: In the FORCE SENSING scenario, a compliant robot manipulator senses if beverage containers are filled by lifting them and sensing their weight. Objects must be held upright while moving to prevent spilling, unless they are known to be completely empty or unopened. suited for reasoning in structured, partially-known environments of the kind that arise in many robot scenarios. While PKS has been used successfully in previous robot domains (Petrick et al. 2009), it lacks certain features which could improve its applicability to a wider range of robotics tasks. In this paper, we describe a set of extensions designed to improve PKS’s ability to generate plans in realworld robot scenarios, by focusing on three tasks: combining high-level symbolic planning with low-level motion planning, reasoning about noisy sensors and effectors, and facilitating planner-level software integration on robot platforms. The planner has also been integrated into a larger software framework called Knowledge of Volumes for robot task Planning (KVP) (Gaschler et al. 2013a), aimed at facilitating the use of planning techniques on a variety of robot platforms (see Figures 1 and 5), which has been developed as part of the JAMES project.1 This framework serves as the basis for the robot demonstrators we describe below. The rest of this paper is organised as follows. We first See http://james-project.eu/ for more information. present an overview of PKS and then describe three extensions to the basic planning system which enhance its ability to operate in robotics domains. We then give three examples of robot domains where we use the extended version of the planner to generate solutions; the first two domains are tested on real robots, while the third domain is tested in simulation. Finally, we situate our approach with respect to related research and discuss future directions of our work. Planning with Knowledge and Sensing (PKS) PKS (Planning with Knowledge and Sensing) is a contingent planner that builds plans in the presence of incomplete information and sensing actions (Petrick and Bacchus 2002; 2004). PKS works at the knowledge level by reasoning about how the planner’s knowledge state, rather than the world state, changes due to action. PKS works with a restricted subset of a first-order logical language, and limited inference. Thus, unlike planners that reason directly with possible worlds models or belief states, PKS works with a set of formulae representing the planner’s knowledge state. This enables it to support a rich representation with features such as functions and variables; however, as a trade-off, its restricted representation means that the planner cannot model certain types of knowledge. PKS is based on a generalisation of STRIPS (Fikes and Nilsson 1971). In STRIPS, the state of the world is modelled by a single database. Actions update this database and, by doing so, update the planner’s world model. In PKS, the planner’s knowledge state, rather than the world state, is represented by a set of five databases, each of which models a particular type of knowledge. The contents of these databases have a fixed, formal interpretation in a modal logic of knowledge. Actions can modify any of the databases, which has the effect of updating the planner’s knowledge state. To ensure efficient inference, PKS restricts the type of knowledge (especially disjunctions) that it can represent. The contents of the databases are as follows: Kf : This database is like a STRIPS database except that both positive and negative facts are permitted and the closed world assumption is not applied. Kf is used for modelling action effects that change the world. Kf can include any ground literal `, where ` ∈ Kf means “the planner knows `.” Kf can also contain known function (in)equality mappings. Kw: This database models the plan-time effects of sensing actions with binary outcomes. φ ∈ Kw means that at plan time the planner either “knows φ or knows ¬φ,” and that at execution time this disjunction will be resolved. In such cases we will also say that the planner “knows whether φ.” Know-whether information is important since PKS uses such knowledge to construct conditional plans (see below). Kv: This database stores information about function values that will become known at execution time. In particular, Kv can model the plan-time effects of sensing actions that return constants, such as numeric values. Kv can contain any unnested function term f , where f ∈ Kv means that at plan time the planner “knows the value of f .” At execution time, the planner will have definite information about f ’s value. As a result, PKS is able to use Kv terms as run-time variables (Etzioni et al. 1992) in its plans. Kx: This database models the planner’s exclusive-or knowledge. Entries in Kx have the form (`1|`2| . . . |`n), where each `i is a ground literal. Such formulae represent a particular type of disjunctive knowledge that arises in many planning scenarios, namely that “exactly one of the `i is true.” LCW: This database stores the planner’s local closed world information (Etzioni, Golden, and Weld 1994), i.e., instances where the planner has complete information about the state of the world. We will not use LCW in this paper. PKS’s databases can be inspected through a set of primitive queries that ask simple questions about the planner’s knowledge state. Simple knowledge assertions can be tested with a query K(φ) which asks: “is a formula φ true?” A queryKw(φ) asks whether φ is known to be true or known to be false (i.e., does the planner “know whether φ”). A query Kv(t) asks “is the value of function t known?” The negation of the above queries can also be used. An inference procedure is used to evaluate primitive queries by checking the contents of the databases, taking into consideration the interaction between different types of knowledge. An action in PKS is modelled by a set of preconditions that query the agent’s knowledge state, and a set of effects that update the state. Action preconditions are simply a list of primitive queries. Action effects are described by a collection of STRIPS-style “add” and “delete” operations that modify the contents of individual databases. E.g., add(Kf , φ) adds φ to Kf , and del(Kw, φ) removes φ from Kw. Actions can also have ADL-style context-dependent effects (Pednault 1989), where the secondary preconditions of an effect are described by lists of primitive queries. A simple form of quantification, ∀x and ∃x, that ranges over known instantiations of x can also be used. Examples of PKS actions are shown below in Figure 3. PKS constructs plans by reasoning about actions in a simple forward-chaining manner: if the preconditions of an action are satisfied by the planner’s knowledge state, then the action’s effects are applied to produce a new knowledge state. Planning then continues from the resulting state. PKS can also build contingent plans with branches, by considering the possible outcomes of its Kw and Kv knowledge. For instance, if φ ∈ Kw then PKS can construct two conditional branches in a plan: along one branch (the K branch) φ is assumed to be known (i.e., φ is added to Kf ), while along the other branch (the K− branch), ¬φ is assumed to be known (i.e., ¬φ is added to Kf ). A similar type of multiway branching plan can also be built by considering a restricted type of Kv information. Planning continues along each branch until the goal—a list of primitive queries–is satisfied. A sample plan with branches is shown in Figure 4, and described in greater detail below. Extensions to PKS for Robot Task Planning In this section we consider three recent extensions to the basic PKS system which we believe are particularly useful for robot task planning. First, we describe a mechanism which allows externally-defined procedures (e.g., from support libraries) to be integrated with the internal reasoning mechanisms of the planner. Second, we present an extension of the PKS representation which allows a form of noisy numerical information to be modelled, for instance to represent the effects of error prone sensors. Finally, we describe a software-level application programming interface to PKS, which aids in the engineering task of integrating the planner with a robot system. Executing Externally-Defined Procedures The first extension we describe aims to take advantage of existing reasoning tools by providing a mechanism for PKS to invoke externally-defined procedures (e.g., defined in special purpose libraries) from within the planner’s internal reasoning mechanism during plan generation. While this idea is not new, and has been successfully applied in other contexts (see the discussion section, below), the introduction of this technique into PKS is a recent extension to the planner. In particular, PKS provides an external query mechanism of the form: extern(proc(~x)), where extern is a special keyword indicating that control should be transferred to an external procedure with the name proc. ~x is a set of parameters that should be passed to proc. In general, x can contain any symbols defined in PKS’s knowledge state, providing a link between the planner and the externally-defined procedure. An extern call can be used within an action definition, either as a precondition or an effect. The return value of the extern call, defined within the external procedure, is passed back to PKS, which interprets it in the context where it occurs in the action. Additional tests may be performed on this value, which can be assigned to domain properties and included in the planner’s knowledge state. While no restrictions are placed on when such procedures can be used in a planning domain, in practice extern calls are most useful if used for complex or special purpose reasoning that cannot easily be modelled in the planner’s restricted representation language, or where more efficient reasoning engines already exist. The externmechanism provides a powerful tool for PKS to use in robotics domains by augmenting PKS’s core reasoning capabilities with the addition of motion planning, collision detection, and other special purpose robotics libraries. For instance, geometric predicates and continuous motions can be evaluated with extern calls, and reasoned about at the symbolic level, enabling us to solve problem instances which may be difficult to model directly at either the motion planning or symbolic planning level alone. Examples of this process are given below. One important drawback with this facility in its present form, is that there is no control over how long an external procedure may take to execute, or whether it will terminate at all. As a result, we are currently extending our extern implementation to introduce a simple timeout facility that will force external procedure calls to terminate if a specified cutoff time is reached. Currently, however, the domain designer must ensure that any externally-defined procedures operate correctly in the context of a given planning domain. Reasoning with Interval-Valued Fluents One type of sensed information that arises in many realworld robotics contexts is numerical information, which is often necessary for modelling state properties (e.g., the robot is 10 metres from the wall), limited resources (e.g., ensure the robot has enough fuel), constraints (e.g., only grasp an object if its radius is less than 10 cm), or arithmetic operations (e.g., advancing the robot one step reduces its distance to the wall by 1 metre). Reasoning with incomplete numerical information is often problematic, however, especially when planners represent incompletely known state properties by sets of states, each of which denotes a possible configuration of the actual world state. E.g., if a fluent f could map to any natural number between 1 and 100, then we require 100 states to capture f ’s possible mappings. The state explosion resulting from large sets of mappings can be computationally difficult for planners that must reason directly with individual states to construct plans. In PKS, we build on a previous planning approach (Petrick 2011) which uses interval-valued fluents (IVFs) (Funge 1998) to avoid some of the computational problems involved with uncertain numerical information. The idea is simple: instead of representing each possible mapping by a separate state, a single interval mapping is used, where the endpoints of the interval indicate the fluent’s range of possible values. Thus, a fluent f that could map to values between 1 and 100 can be denoted in an interval-valued form by f = 〈1, 100〉. In general, PKS treats each IVF as a function whose denotation is an interval of the form 〈u, v〉. The endpoints of the interval, u and v, indicate the bounds on the range of possible mappings for the fluent. Since we are interested in planning with incomplete information, a mapping f = 〈u, v〉 will mean that the value of f is known to be in the interval 〈u, v〉. If a fluent maps to a point interval of the form 〈u, u〉, then the mapping is certain and known to be equal to u. PKS’s knowledge of (general) IVFs are stored in its Kx database, as a generalisation of its exclusive-or information. In addition to basic intervals, disjunctive intervals (i.e., sets of disjoint interval mappings) are also permitted. For instance, if a fluent f could possibly map to any value between 5 and 10 or, alternatively, map to values between 15 and 18, we can represent such information by the Kx formula (f = 〈5, 10〉 |f = 〈15, 18〉). Certain types of IVFs can also be represented in the Kv and Kw databases. For instance, a fluent of the form f : 〈x− c, x+ c〉 in Kv means that the value of the fluent f is known, and f is in the range x ± c, for some numeric constant c and unknown fluent value x. This mechanism can be used to model the results of noisy sensors. In Kw, we also permit numeric relations of the form f op c, where op ∈ {=, 6=, >,<,≥,≤} and c is a numeric constant. Thus, f > 5 ∈ Kw can be used to model a sensing action that determines whether f is greater than 5 or not. Since Kw is used to build contingent branches into a plan, this extension also enables PKS to build branches based on IVFs. An Application Programming Interface The task of integrating a planner onto a robot platform often centres around the problem of representation, and how to abstract the capabilities of a robot and its working environment so that it can be put in a suitable form for use by the planner. Integration also typically requires the ability to communicate information between system components. Thus, the integration of a planning system usually requires a consideration of certain engineering-level concerns, to ensure proper interoperability with components that aren’t traditionally considered in theoretical planning settings. In order to facilitate the task of providing software-level planning services to robot systems, we have created an application programming interface (API) for a version of PKS implemented as a C++ library. This interface abstracts many common planning operations into a series of functions which provide direct access to these services. For instance, this interface includes methods for manipulating domain representations, as well as functions for controlling certain aspects of the the plan generation process itself (e.g., selecting goals, generation strategies, or planner-specific settings). Moreover, functions that allow plans to be manipulated as first-class entities (e.g., for replanning) are provided. A fragment of the API is given in Figure 2. Overall, the API is designed to be generic and is not meant to be tied to one particular planning system. For instance, the planner configuration methods are meant to provide a way to set certain properties of the underlying planning system, and provide access to features needed for debugging. The domain configuration functions provide the main methods for defining planning domain models, either from traditional domain/problem files, or via string-based descriptions. One important idea behind the configuration functions is that they offer the possibility of specifying domains to the planner incrementally, using function calls alone, rather than specifying a single monolithic domain file. This means that an initial domain could be specified and then later revised, for instance due to additional information discovered by the robot during execution (e.g., new domain objects, revised action descriptions, additional properties corresponding to new capabilities of the robot, etc.). Finally, the plan generation and iteration functions specify methods for controlling various aspects of the plan generation process, and provide a way for processes external to the planner to control simple monitoring and replanning activities, including updates to certain aspects of the planning problem, such as goal change. We will discuss the integration of PKS on our robot platforms in greater detail in the discussion section below. Example Domains To demonstrate our approach, we now describe three robotics scenarios that make use of knowledge-level planning: the FORCE SENSING and the BIMANUAL robot scenarios, based on domains first described in (Gaschler et al. 2013c) and tested on real robots, and the ROBOT LOCALISATION scenario, tested in simulation. In all scenarios, the robot uses sensing actions to obtain knowledge of some domain property which is necessary for achieving the goal. In the first scenario, only the basic PKS system is used. In the second scenario, PKS’s external procedure mechanism is used to link a motion planning library to the planner’s internal reasoning mechanisms. In the final scenario, we make // Configuration and debugging